1. Field of the Invention
This invention relates in general to an improved method of managing design data for an integrated circuit for computers and digital systems and, in particular, to the management of design data associated with many unique physical copies of one logical entity.
2. Description of Background
The need to customize individual physical copies (known as “instances”) of a particular building block, or macro, for an integrated circuit is becoming more common as the complexity and performance of those circuits increase. These macros can be as simple as a buffer or IO book, or as complex as an entire microprocessor core, as well as anything in between. There are numerous design requirements that drive the need for customization including, but not limited to; timing, power, physical form factor, physical orientation and circuit performance.
In past generations of digital and computer designs this was rarely a problem, as a conservative design approach could easily accommodate the physical constraints and requirements surrounding all the instances. The simple method of placing multiple identical copies of a macro on an integrated circuit was sufficient to meet the requirements of the design.
As the technologies and designs have evolved, this is becoming increasingly more difficult. For example, the clock speeds of present day microprocessors often require customized timing assertions and solutions not just for macros, but for each instance of every macro. Another example requiring customization is different physical orientation of an instance's copies. Older CMOS technologies accommodated various orientations of CMOS FET gates. However, in current CMOS technologies FET gates are often required to be aligned in one direction across the entire integrated circuit chip. So with a technology that requires FETS to be aligned in parallel, a simple chip floor planning operation like rotating one copy of an instance 90 degrees will require a new physical design for that copy with the gates in the original orientation. Likewise, in floor planning the chip the space available may require that various copies of an instance have different aspect ratios. Again, that requires the creation of unique physical instances. Another example is the tuning of IO book resistors, where there is one functionally all the IO books are identical but physically different resistor values are placed in the books to match the impedance of the line. All these eases require customization of the physical instance.
The data that describes a particular macro are typically stored in a database under the direction of Design Data Manager (DDM) that synchronizes and provides interlocks and accountability for the data. This data may consist of the logical description of the block (created with a tool using VHDL, Verilog, etc.), timing rules, audit status, physical implementation, and other data sets associated with a particular block. Computer Aided Design (CAD) tools use the data to craft an integrated circuit chip. Also the data sets provide information on the history, validity and authenticity of the design.
For the case of a macro that is replicated many times where all physical copies are identical, then the data management is straightforward since all copies can refer to the same master data sets. However in the eases described earlier, where the physical implementation of a copy has been customized then unique data sets that describe that physical implementation must be maintained in the database. Unfortunately many CAD tools and IC design methodologies require a consistent nomenclature of design entities and do not support sharing of data sets across design entities. These restrictions require a complete copy of all data sets for each unique physical copy even though many of the data sets may be identical. For example, the logical (VHDL) description may be the same for all IO books, but there may be hundreds of physical books with different resistor values, creating a need for hundreds of identical entries in the design database.
Historically, the common brute force approach was to make copies of all the data sets for each customized copy being used. This approach is simple and fits in with existing methodologies and data management. However, any logical updates must be replicated across all copies. For one or two copies of one or two logically unique blocks these approach works without much additional overhead. However the need to maintain hundreds or even thousands of copies becomes difficult and unwieldy with a brute force approach.
Another approach is to selectively copy the required data sets (physical design data), while keeping a single copy of the data sets that are common (logical data sets like VHDL data sets). This approach is desirable since it enables the common data to be easily managed, maintained and verified. However, as mentioned before most CAD tools and design methodologies enforce a consistent nomenclature of design entities and prevent the selective approach.
What is needed is a method that allows fi)r maintaining a single copy of data sets with a plurality of instances and yet allows for unique data sets describing the unique features of those instances that works within the framework of existing design databases and with existing CAD tools.